package mysql8学习.高级.第06章_索引的数据结构;

/**
 * 思考题:为了减少I0,索引树会一次性加载吗?
 *      1、数据库索引是存储在磁盘上的，如果数据量很大，必然导致索引的大小也会很大，超过几个G。
 *      2、当我们利用索引查询时候，是不可能将全部几个G的索引都加载进内存的，我们能做的只能是:逐一加载
 *
 * 思考题: B+树的存储能力如何?为何说一般查找行记录，最多只需1~3次磁盘I/O
 *    InnoDB存储引擎中页的大小为16KB，
 *    一般表的主键类型为INT (占用4个字节)或BIGINT (占用8个字节)，指针类型也一般为4或8个字节，
 *    也就是说一个页(B+Tree 中的一个节点)中大概存储16K/(8B+8B)=1K个键值
 *      因为是估值，为方便计算，这里的K取值为10^3。
 *      也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿条记录。
 *      (这里假定一个数据页也存储10^3条行记录数据了)
 *
 *    实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree 的高度一般都在 2~4层。
 *    MySQL 的InnoDB存储引擎在设计时是将根节点常驻内存的，
 *    也就是说查找某一键值的行记录时最多只需要1-3次磁盘I/O操作。
 *
 * 思考题: 为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引?
 *   1、B+树的磁盘读写代价更低
 *     B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B树更小。
 *     如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。
 *     一次性读入内存中的需要查找的关键字也就越多。相对来说I/O读写次数也就降低了。
 *   2、B+树的查询效率更加稳定
 *    由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。
 *    所以任何关键字的查找必须走一条从根结点到叶子结点的路。
 *    所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
 *
 * 思考题: Hash 索引与B+树索引的区别
 *    我们之前讲到过B+树索引的结构，Hash 索引结构和B+树的不同，因此在索引使用上也会有差别。
 *    1、Hash 索引不能进行范围查询，而B+树可以。
 *      这是因为Hash索引指向的数据是无序的，而B+树的叶子节点是个有序的链表。
 *    2、Hash 索引不支持联合索引的最左侧原则(即联合索引的部分索引无法使用)，而B+树可以。
 *    对于联合索引来说，Hash 索引在计算Hash值的时候是将索引键合并后再一起计算Hash值，
 *    所以不会针对每个索引单独计算Hash值。
 *    因此如果用到联合索引的一个或者几个索引时，联合索引无法被利用。
 *    3、 Hash索引不支持ORDER BY排序，因为Hash索引指向的数据是无序的，
 *    因此无法起到排序优化的作用，而B+树索引数据是有序的，可以起到对该字段ORDER BY排序优化的作用。
 *    同理，我们也无法用Hash索引进行模糊查询，而B+树使用LIKE进行模糊查询的时候，
 *    LIKE 后面后模糊查询(比如%结尾)的话就可以起到优化作用。
 *    4、InnoDB不支持哈希索引
 *
 * 思考题: Hash 索引与B+树索引是在建索引的时候手动指定的吗?
 *    如果使用的是MySQL的话，我们需要了解MySQL的存储引擎都支持哪些索引结构，
 *    你能看到，针对InnoDB和MyISAM存储引擎，都会默认采用B+树索引，无法使用Hash索引。
 *    InnoDB 提供的自适应Hash是不需要手动指定的。
 *    如果是Memory/Heap和NDB存储引擎，是可以进行选择Hash索引的。
 *
 *
 */
public class J6_B加树思考 {
}



